1. Field of the Invention
The present invention relates to a system for managing and processing object transactions in a network of distributed resources operating in the client-server mode, wherein the client sends a request to at least one transaction object contained in at least one of the servers distributed across the network, while a transaction manager dialogues with a resource manager through a predefined interface and by means of a transaction validation protocol. It also relates to the process implemented by this system.
2. Description of Related Art
Traditionally, and for a long time, the control and management of transaction data have been carried out by means of centralized mainframe computers. These machines were initially accessible locally, then later through networks which became increasingly complex, but were still hierarchical. It is only more recently that the distributed model based on open systems has been used. Generally, a distributed management environment makes it possible to integrate the administration of systems, networks and user applications, the dialogue between the various machines of the system and/or between the various users being organized around requests and responses to these requests, the most common requests in a network being related to file access or data access. An application is said to be designed according to a "client-server" architecture when it is comprised of two independent programs which cooperate with one another to implement the same process, each of which runs in an environment of its own (machine, operating system), and a programming interface using a language composed of commands makes it possible to control their dialogue. The client-server mode has the advantage of enabling a user (for example a simple microcomputer) called a client to delegate part of its task or its operations to be executed to a server. In this way, the client has at its disposal a computing capacity much greater than that of its own microcomputer. Likewise, a client can address a specialized server and effectively outsource an operation, the server being under optimal conditions in terms of implementation and expertise due to its specialization. In this context, the object of the transaction processing service is to provide the specific functions required for running applications which modify a given situation in real time. Transaction processing applications use services which guarantee that the transactions are carried out completely or are not executed at all. It must be recalled here that a transaction is a set of commands which have no significance unless all of them are executed, a concept which guarantees the consistency and the integrity of the data. The completion of transactions, which is known as validation or consolidation ("commitment" to one skilled in the art), must consequently have certain characteristics. Thus, the transaction processing service must ensure that the transaction applications are "Atomic," "Consistent," "Isolated" and "Durable" (ACID), "atomic" meaning that all the elements of the transaction are processed or no element is processed, "coherent" meaning that if any part of the transaction is not executed, all the parts of the system affected by this transaction remain in their original state, "isolated" meaning that during the processing of a transaction, the shared resources of the system are not accessible to another transaction, "durable" meaning that the results of a completed transaction are permanent and are not lost, and thus that in case of a fault or failure, the transaction is not lost. All of these properties consequently make it possible to keep the data, which constitute a non-negligible part of the property of an organization, consistent and constantly updated no matter what type of failure occurs (program, system, hardware, or communications). Providing these properties has become more difficult as the transaction systems themselves have become more sophisticated. At the present time, transactions generally involve a plurality of systems and affect various data bases as well as various types of resources. In order to manage these systems, the transaction processing service manages the resources so as to guarantee the coordination of the validations and provides specialized communications for managing the distributed transaction processing applications. The transaction processing service must also coordinate the various applications which must be involved in processing a global transaction. For this reason, the transaction environment must offer a certain flexibility, the "X/OPEN" environment being a good example in that it makes it possible to effectively complement the transaction processing services working on large volumes of transactions and to manage an architecture using distributed transaction processing. In this way, the applications can use distributed data bases in a transparent manner.
In the field of object-oriented applications, a certain number of rules have been adopted for defining a common object, giving birth to the distributed object model. The OMG (Object Management Group) has been particularly active in managing this problem, proposing models, definitions and an architecture which effectively respond to the various concerns of the industry. In effect, a unique architecture using an object-oriented technology has been developed for allowing easy integration of distributed applications by guaranteeing the re-use of components already created, interoperability and portability, as well as the availability of software interfaces for simple and rapid use of the products on the market. According to the OMG definition, an object is the "combination of a state and a set of methods," which object can be any resource that responds to requests specific to services. In order to provide a common architecture that makes it possible to respond to these requests, the OMG has defined a reference model having four main components. The first is the ORB (Object Request Broker), a software bus which is in fact a set of devices which, in a distributed environment and in a completely transparent manner, enable a client to send requests to (and receive responses from) objects distributed across a network, without concern for the location of these objects. The second corresponds to a set of services called object services, which provide interfaces and objects having basic functions for creating and maintaining objects, functions such as persistence, naming, event notification, transactions, etc. The third component relates to the common services, which provide a set of interfaces and objects offering general functions that can be used by a large number of applications or systems independently from the domain of the application, facilities such as printing, intermediate storage, electronic mail or so-called intelligent agents. The fourth component provides application objects specific to determined user applications such as, for example, orders, bills, clients, etc.
More particularly, in this transaction context, the "X/OPEN" distributed transaction processing model defines resource managers as being components which authorize access to shared resources such as data bases, file systems or print servers. A resource wherein the data are assigned by the validation ("commit") or cancellation ("rollback") of a transaction is said to be recoverable. In the case of a validation ("commit"), the modifications and updates already executed are rendered effective, in the case of a cancellation ("rollback"), the resource remains in its original state before the transaction, and in case of error, the operations of the transaction in progress are cancelled. By controlling access to a recoverable shared resource, the resource manager makes it possible to guarantee that this resource will return to a consistent state after any potential failure. X/OPEN defines an interface, the XA interface, between the transaction manager and the resource manager. This predefined and standardized interface allows the involvement and the cooperation of heterogeneous resource managers in a single distributed transaction and adheres to a selected two-phase commit protocol managed by the transaction manager. The main interactions in the X/OPEN distributed transaction processing model are the following. First, a client application initiates a transaction, then by sending requests, it involves shared resources to which the transaction relates, which shared resources are managed by resource managers. Next, the client application starts and finishes the transaction. At the completion of the transaction, the transaction manager contacts the resource servers and coordinates the two-phase commit protocol through the XA interface. However, a technological choice of this type has considerable drawbacks, particularly due to the complexity of the utilization of this interface by a server in this transaction environment. In effect, in order to execute a transaction, a server intending to use a data base must use this interface from the start to indicate its participation in this transaction and its intention to use the data base, and each time requests arrive, it must specify that the latter are part of the transaction, after which it completes its participation in the transaction, a response to the requests having been provided, while moreover, it must be able to communicate with the transaction manager so as to be capable of reacting to its promptings during the implementation of the two-phase commit protocol. This dialogue with the predefined interface becomes even more complex the larger the number of data bases this server intends to access. Moreover, the requests passing through the ORB only add to the complexity of a utilization of this type. Finally, the compatibility between relational data base systems and the specifications of the XA interface is far from complete, rendering any true portability problematic.